A content distribution network delivers content of a variety of types to users communicatively connected to the content distribution network. The users may connect to the content distribution network, such as a wireless, cable, fiber, satellite or a hybrid network via, for example, a networked data receiver, such as a gateway set top box (CPE), an end user device, or the like. CPEs for example, are frequently provided to customers of content distribution networks operated by various operators. Distributed content types may include, for example, file based assets, such as video, audio, metadata, and optional interactive TV applications and/or triggers packaged into a file format and/or interactive TV (iTV). As used herein, iTV assets may be, for example, interactive TV applications and/or triggers, and data such as business rules encapsulated with metadata. File based assets may include video-on-demand (VOD) sets, advertising assets, motion video advertisements, still video advertisements, overlay advertisements, or other content.
In a typical content distribution network, a facility may service multiple regional networks, such as converged regional area networks (CRAN). One or more CRANs may service one or more gateway servers, and may additionally service one or more edge servers. Edge servers, or like devices may additionally provide services to gateways, CPEs, and similar devices, and may be referred to as hub servers.
File based assets are typically encoded for distribution and delivery over the content distribution network. The file based assets may be decoded upon receipt, such as by the edge server, or by the gateway, or by the receiving CPE, for example. Typically, distribution networks require encoding at constant bit rates.
Constant bit rate encoding has historically presented several concerns. To address such concerns, for example, file based assets may be “padded,” such as using null packets, for encoding. In other words, if the packetization of the file based asset is inadequate in number to account for the constant bit rate set for encoding, additional packets, which are blank, or null, may be added in order to provide a sufficient number of packets to account for the constant bit rate. The addition of null packets in order to allow for a particular constant bit rate causes an inability to take advantage, for example, of an increase in bit rates, at least in that the increased bits may be devoid of content, and thus may not improve the video quality despite an increased bit rate. On the other hand, a constant bit rate may cause a lesser video quality than the file based asset would otherwise allow.
For standard definition VOD, for example, file based assets may be encoded at 3.75 Mb/s. For simple, “talking head” type video content, 3.75 Mb/s is typically a sufficient bit rate to provide an acceptable video quality. In order to achieve a constant bit rate of 3.75 Mb/s, null packets are typically inserted into such content. However, for video content containing fast movement, such as a sporting event like NFL action or highlights, for example, a 3.75 Mb/s bit rate may result in a poor video experience. The poor video experience may suffer further due at least in part to the presence of null packets that were inserted to achieve the desired constant bit rate.
Several solutions have been proposed for video quality issues that arise due to encoding at a constant bit rate, including solutions for constant rate encoding issues with regard to Internet protocol (IP) communications. For typical IP encoding, the initial asset may be decoded from an initial format and played in its entirety, during which time the encoder encodes the asset, in real time, for example, to a new format. Thus, for example, a MPEG video may be “transcoded” into a Flash video by decoding and playing the MPEG video, during which play the MPEG video would be re-encoded to the Flash video format.
As be apparent to those skilled in the art, each of the proposed solutions to the issues presented by constant bit rate encoding has significant drawbacks. For example, transcoding takes significant time, at least in that the asset must be played in full after initial decoding in order to allow for the transcoder to re-encode into a new format and/or bit rate. More recent transcoders break the file into smaller sets, or “chunks”, transcode the chunks, and reassemble them so as to reduce the total amount of time for transcoding. Other proposed solutions, such as filling with packets, increasing bit rate, or initially using variable bit rates, may not provide uniform improvement in video quality, because, for example such solutions would improve the video quality only of low bit rate content. As such, it would at first seem desirable to simply increase the standard bit rate, such as from 3.75 Mb/s to 7.5 Mb/s. However, such may lead to bandwidth issues and losing distinctions between video quality.
Therefore, a need exists for a system, method and device to provide dynamic encoding, such as changes in bit rates, using a system to change bit rates for file based video assets, wherein the system may select an optimal bit rate from among a plurality of bit rate in order to obtain a particular video quality and/or format.